在android studio 3.0 版本之前，第三方库或者module的依赖方式有compile、implementation。android studio 3.0 版本之后，compile被取代，改用API dependency，实质完全等同于compile。

概念 : 将该依赖隐藏在内部，而不对外部公开。

理解 : 在 app mudule 中使用 implement 依赖的第三方库, 在其他 mudule 是无法调用的.

举例 : 此时项目中有一个 mudule 是 ImageLoader ,其内部用 implement 指令依赖了 glide 这个库, 那么此时我们在 app mudule 中无法调用 glide 库中的方法.

概念: android studio 3.0 版本后废弃该指令 改用 api 代替, api 完全等同于之前的 compile 指令, 也就是普通的依赖, 第三方库在 mudule 中依赖后其他 mudule 都可以使用该库.

官方推荐在不影响的前提下优先使用 implement 指令依赖.

对比Implementation 变化 & compile 变化 ：

Implementation 变化 

当本module依赖的ib(也可以是module)发生变化时，由于本module对外暴露的接口并不发生变化，在构建工程时gradle将会只重新编译本module，所有依赖于本module的module并不会发生编译。这种情况是没什么问题的。如图所示。

compile 变化 

当本module依赖的lib(也可以是module)发生变化时，本module向外暴露的接口发生了变化，那么所有直接依赖于本module的module将不得不重新编译。

接下来，这些上层module可能通过其本身的接口对外暴露了底层module的部分内容，即意味着本module暴露的接口也发生了变化，这会使得依赖于上层module的上上层module也需要重新编译。这就导致了一个连锁效应，因此，为了绝对的安全起见，gradle将不得不重新编译整个工程，使得编译时间变得较长。如图所示。

那么重点来了：一点代码的改动可能会引起整个工程的重新编译，这将是多么悲催，而实际上我们之前的gradle插件2.0版本系列的确如此，根本原因就是gradle压根不知道暴露的接口可以通过一个接一个的依赖传递影响整个工程。

所以更好的方式就是使用implementation来进行依赖，这会大大改善工程的构建时间。只有你明确要向外部暴露所依赖lib的接口时，才需要使用api依赖，整体来说，会减少很多重新编译。这一点，在官方指南中说的比较明确。